Language/OS - Multiplatform Resource Library/LANGUAGE OS.iso/ast_text/faqs/g!!-faqs/plain

Internet Message Format | 1993-06-28 | 30.9 KB

Path: senator-bedfellow.mit.edu!enterpoop.mit.edu!news.media.mit.edu!uhog.mit.edu!rutgers!newsserver.jvnc.net!howland.reston.ans.net!agate!usenet
From: [e-mail] (Joe Buck)
Newsgroups: gnu.g++.help,comp.lang.c++,news.answers,comp.answers
Subject: FAQ for g++ and libg++, plain text version [Revised 15 Jun 1993]
Message-ID: <[e-mail]>
Date: 15 Jun 93 16:21:23 GMT
Expires: 15 Jul 1993 00:00:00 GMT
Followup-To: poster
Organization: University of California, Berkeley
Lines: 753
Approved: [e-mail]
Supersedes: <[e-mail]>
NNTP-Posting-Host: forney.eecs.berkeley.edu
Xref: senator-bedfellow.mit.edu gnu.g++.help:3627 comp.lang.c++:45304 news.answers:9430 comp.answers:1010

Archive-name: g++-FAQ/plain
Last-modified: 15 Jun 1993
Frequency: bimonthly

[ this is the plain text version, the parent is the texinfo version ]


Preface
*******

   This is a list of frequently asked questions (FAQ) for g++ users;
thanks to all those who sent suggestions for improvements.  Thanks to
Marcus Speh for doing the index.

   Many FAQ's, including this one, are available on the archive site
rtfm.mit.edu, in the directory pub/usenet/news.answers.  This FAQ may
be found in the subdirectory g++-FAQ.

   There have been many, many changes since the last version of this
list, prompted by a major release of gcc.  I've fixed this document as
best I could, but I'm sure it will need some more work.  Please send
fixes, and please be kind.

   I'm looking for new questions (*with* answers), better answers, or
both.  One thing that's missing is a section on templates and template
problems with g++; I'm looking for contributions on this score.  You
can mail comments, suggestions, flames, etc. to [e-mail].
Please don't assume, though, that because my name is on this thing
that I am the world expert on g++/C++ and you should mail all your
tricky questions to me.  I'd like to be helpful but I'm getting more of
this than I can deal with lately.

   This FAQ is intended to supplement, not replace, Marshall Cline's
excellent FAQ for comp.lang.c++.  Especially if g++ is the first C++
compiler you've ever used, the question "How do I do <X> with g++?" is
probably really "How do I do <X> in C++?".  You can obtain the C++ FAQ
by anonymous FTP from sun.soe.clarkson.edu [128.153.12.3], in the file
~ftp/pub/C++/FAQ.  (There is also a mail server for that FAQ, but it
seems to be broken).


Obtaining Source Code
*********************


How do I get a copy of g++ for Unix?
====================================

   First, you may already have it if you have gcc for your platform;
g++ and gcc are combined now (as of gcc version 2.0).

   You can get g++ from a friend who has a copy, by anonymous FTP or
UUCP, or by ordering a tape or CD-ROM from the Free Software Foundation.

   The Free Software Foundation is a nonprofit organization that
distributes software and manuals to raise funds for more GNU
development.  Getting your copy from the FSF contributes directly to
paying staff to develop GNU software.  CD-ROMs cost $100 if an
individual is buying, or $400 if an organization is buying.  Tapes cost
around $200 depending on media type.  I recommend asking for version 2,
not version 1, of g++.

   For more information about ordering from the FSF, contact
[e-mail] or phone [phone].

   Here is a list of anonymous FTP archive sites for GNU software.

     Japan: ftp.cs.titech.ac.jp, utsun.s.u-tokyo.ac.jp:ftpsync/prep
     Australia: archie.au:gnu
     Europe: src.doc.ic.ac.uk:gnu, ftp.informatik.tu-muenchen.de,
         ftp.informatik.rwth-aachen.de:pub/gnu,
         nic.funet.fi:pub/gnu, ugle.unit.no, isy.liu.se,
         ftp.stacken.kth.se, sunic.sunet.se, ftp.win.tue.nl,
         ftp.diku.dk, ftp.eunet.ch, archive.eu.net
     United States: wuarchive.wustl.edu, ftp.cs.widener.edu,
         uxc.cso.uiuc.edu, col.hp.com, gatekeeper.dec.com:pub/GNU,
         ftp.uu.net:packages/gnu

   The "official site" is prep.ai.mit.edu, but your transfer will
probably go faster if you use one of the above machines.

   If you use the HP Precision Architecture (HP-9000/7xx and
HP-9000/8xx) and you want to use debugging, you'll need to grab a
special version of GAS from the University of Utah, site
jaguar.cs.utah.edu.  Look in the "/dist" directory for pa-gas-1.36.u5.
A non-standard debug format is used, since HP considers their debug
format a trade secret.  The GNU debugger, GDB, understands the debug
format produced by this version of GAS, but not the format produced by
HP's compilers.

   Some enhancements for the HP that haven't been integrated back into
the official gcc are available from the same site in version
gcc-2.4.3.u2.  The main one seems to be that linking against HPUX
shared libraries works.  Both sources and precompiled binaries are
available from this site.

   libg++-2.3 requires some patches to install correctly on HP-PA
systems.  You may obtain these patches by anonymous FTP from the site
geod.emr.ca in /pub/hp/libg++-2.3.patches.tar.Z.  Other interesting
notes for HP-PA folks on use of GNU software on this architecture may
be found in the file "gnu-results-1.6" in the same directory (1.6 may
be replaced with some later number).

   [ I don't know how the above changes with libg++ 2.3.1 - jbuck ]

   UUNET customers can get GNU sources from UUNET via UUCP.  UUCP-only
sites can get GNU sources by "anonymous UUCP" from site "osu-cis" at
Ohio State University.  You pay for the long-distance call to OSU; the
price isn't too bad on weekends at 9600 bps.  Send mail to
[e-mail] or osu-cis!uucp for more information.

   OSU lines are often busy.  If you're in the USA, and are willing to
spend more money, you can get sources via UUCP from UUNET using their
900 number: 1-900-GOT-SRCS (900 numbers don't work internationally).
You will be billed $0.50/minute by your phone company.

   Don't forget to retrieve libg++ as well!


Getting gcc/g++ binaries for Solaris 2.x
========================================

   "Sun took the C compiler out of Solaris 2.x.  Am I stuck?"

   No; prep.ai.mit.edu and its mirror sites provide GCC binaries for
Solaris.  As a rule, these binaries are not updated as often as the
sources are, so if you want the very latest version of gcc/g++, you may
need to grab and install binaries for an older version and use it to
bootstrap the latest version from source.

   The latest gcc binaries on prep.ai.mit.edu are for version 2.4.0.


How do I get a copy of g++ for (some other platform)?
=====================================================

   The standard gcc/g++ distribution includes VMS support.  Since the
FSF people don't use VMS, it's likely to be somewhat less solid than
the Unix version.  Precompiled copies of g++ and libg++ in
VMS-installable form are available by FTP from mango.rsmas.miami.edu.

   DJ Delorie has ported gcc/g++ to MS-DOS; this port is popularly
known as "DJGPP" (the P's stand for "plus").  It can be found on many
FTP archive sites; its "home" is on omnigate.clarkson.edu, directory
~ftp/pub/msdos/djgpp.  Note: omnigate restricts the number of anonymous
users.  The latest version of DJGPP is 1.10, announced on June 1, 1993.
This version is the first that runs under Windows 3.x.  It is a port
of gcc 2.4.1.

   For information on Amiga ports of gcc/g++, retrieve the file
/pub/gnu/MicrosPorts/Amiga from prep.ai.mit.edu, or write to Markus M.
Wild <[e-mail]>, who I hope won't be too upset that I
mentioned his name here.

   A port of gcc-2.4.1 to the Atari ST can be found on the site
"atari.archive.umich.edu", under /atari/Gnustuff/Tos, along with many
other GNU programs.  See the FAQ for the Usenet group
"comp.sys.atari.st" for more information.

   There are two different ports of gcc-2.3.3 (and g++) to OS/2, the
so-called EMX port, which requires a particular Unix emulator, and a
port called "gcc/2", which runs native.  The latter port uses a rather
buggy port of the BSD libc.  For more information ask around on
"comp.os.os2.programmer".  gcc/2, together with other GNUware for OS/2,
can be obtained by FTP from

     ftp-os2.nmsu.edu (128.123.35.151) in /pub/os2/2_x/unix/gnu
     luga.latrobe.edu.au (131.172.2.2) in /pub/os2/2_x/unix/gnu

   The current maintainer of the gcc/2 port is Colin Jensen (Michael
Johnson did the original port).  His address is [e-mail].

   Eberhard Mattes did the EMX port.  His address is
[e-mail].

   Because the legal policies of Apple threaten the long-term goals of
FSF, as well as the concept of free software, no support will be lent to
efforts to port GNU software to Macintosh or other Apple hardware.


But I can only find g++-1.42!
=============================

   "I keep hearing people talking about g++ 2.4.3 (or some other number
starting with 2), but the latest version I can find is g++ 1.42.  Where
is it?"

   As of gcc 2.0, C, C++, and Objective-C as well are all combined into
a single distribution called gcc.  If you get gcc you already have g++.
The standard installation procedure for any gcc version 2 compiler will
install the C++ compiler as well.

   One could argue that we shouldn't even refer to "g++-2.x.y" but it's
a convention.  It means "the C++ compiler included with gcc-2.x.y".


What is the latest version of gcc, g++, and libg++?
===================================================

   The latest "2.x" version of gcc/g++ is 2.4.3, released June 1, 1993.
(version "2.4.3.1" just fixes a problem with the INSTALL file but is
otherwise identical to 2.4.3).  The latest version of libg++ is 2.3.1,
released May 26, 1993.

   For some non-Unix platforms, 2.2.2 may be the latest compiler that
has been ported.  libg++ 2.3 will not compile with gcc-2.2.2; use libg++
2.2 instead.

   The latest "1.x" version of gcc is 1.42, and the latest "1.x"
version of g++ is 1.42.0.  I recommend against using them except in
special circumstances.


Installation Issues and Problems
********************************


The INSTALL file in gcc-2.4.3 is truncated
==========================================

   For some reason, the INSTALL file in the gcc-2.4.3 installation was
truncated at 16384 characters.  Accordingly, there is a distribution
called gcc-2.4.3.1, which is different only that it has a complete
INSTALL file.  You can either get that, or just read the `install.texi'
file, which contains all the same information.


I can't build g++ 1.x.y with gcc-2.x.y!
=======================================

   "I obtained gcc-2.x.y and g++ 1.x.y and I'm trying to build it, but
I'm having major problems.  What's going on?"

   If you wish to build g++-1.42, you must obtain gcc-1.42 first.  The
installation instructions for g++ version 1 leave a lot to be desired,
unfortunately, and I would recommend that, unless you have a special
reason for needing the 1.x compiler, that C++ users use the latest
g++-2.x version, as it is the version that is being actively maintained.

   There is no template support in g++-1.x, and it is generally much
further away from the ANSI draft standard than g++-2.x is.


OK, I've obtained gcc; what else do I need?
===========================================

   First off, you'll want libg++ as you can do almost nothing without it
(unless you replace it with some other class library).

   Second, depending on your platform, you may need "gas", the GNU
assembler, or the GNU linker (see next question).

   Finally, while it is not required, you'll almost certainly want the
GNU debugger, gdb.  The latest version is 4.9, released May 12, 1993.
Other debuggers (like dbx, for example) will normally not be able to
understand at least some of the debug information produced by g++.


Should I use the GNU linker, or should I use "collect"?
=======================================================

   First off, for novices: special measures must be taken with C++ to
arrange for the calling of constructors for global or static objects
before the execution of your program, and for the calling of
destructors at the end.  (Exception: System VR3 and System VR4 linkers
support user-defined segments; g++ on these systems requires neither
the GNU linker nor collect.  So if you have such a system, the answer
is that you don't need either one).

   If you have experience with AT&T's "cfront", this function is
performed there by programs named "patch" or "munch".  With GNU C++, it
is performed either by the GNU linker or by a program known as
"collect".  The collect program is part of the gcc-2.x distribution;
you can obtain the GNU linker separately as part of the "binutils"
package.  The latest version of binutils is 2.2.1, released May 21,
1993.

   (To be technical, it's "collect2"; there were originally several
alternative versions of collect, and this is the one that survived).

   There are advantages and disadvantages to either choice.

   Advantages of the GNU linker:

   It's faster than using collect - collect basically runs the standard
Unix linker on your program twice, inserting some extra code after the
first pass to call the constructors.  This is a sizable time penalty
for large programs.  The GNU linker does not require this extra pass.

   GNU ld reports undefined symbols using their true names, not the
mangled names.

   If there are undefined symbols, GNU ld reports which object file(s)
refer to the undefined symbol(s).

   As of binutils version 2.2, on systems that use the so-called "a.out"
debug format (e.g. Suns running SunOS 4.x), the GNU linker compresses
the debug symbol table considerably, which in at least some cases may
make up, in disk space, for its inability to use shared libraries.

   Advantages of collect:

   If your native linker supports shared libraries, you can use shared
libraries with collect.  The GNU linker does not (yet) support shared
libraries.

   Note: using existing shared libraries (X and libc, for example) works
very nicely; generating shared libraries from g++-compiled code is
another matter, generally requiring OS-dependent tricks if it is
possible at all.

   The GNU linker has not been ported to as many platforms as g++ has,
so you may be forced to use collect.

   If you use collect, you don't need to get something extra and figure
out how to install it; the standard gcc installation procedure will do
it for you.

   In conclusion, I don't see a clear win for either alternative at this
point.  Take your pick.


Should I use the GNU assembler, or my vendor's assembler?
=========================================================

   This depends on your platform and your decision about the GNU
linker.  For most platforms, you'll need to use gas if you use the GNU
linker.  For some platforms, you have no choice; check the gcc
installation notes to see whether you must use gas.  But you can
usually use the vendor's assembler if you don't use the GNU linker.

   The GNU assembler assembles faster than many native assemblers;
however, on many platforms it cannot support the local debugging format.


Should I use the GNU C library?
===============================

   At this point in time, no.  The GNU C library is still very young,
and libg++ still conflicts with it in some places.  Use your native C
library unless you know a lot about the gory details of libg++ and
gnu-libc.  This will probably change in the future.


Problems building libg++ on 386/486
===================================

   Attempts to install libg++ on 386 or 486 systems running ports of
SVR4 have problems because of bugs in debugging support on that
platform.  Briefly, debugging does not currently work right yet for
C++.  You should be able to build the library successfully by deleting
the -g flag from the Makefiles (this should no longer be necessary with
gcc 2.4.1 although debugging still doesn't work).

   See the section entitled "Debugging on SVR4 systems."


Other problems building libg++
==============================

   "I am having trouble building libg++-2.2 or 2.3.  Help!"

   On some platforms (for example, Ultrix), you may see errors
complaining about being unable to open dummy.o.  On other platforms
(for example, SunOS), you may see problems having to do with the type
of size_t.  The fix for these problems is to make libg++ by saying
"make CC=gcc".  According to Per Bothner, it should no longer be
necessary to specify "CC=gcc" for libg++-2.3.1.

   On Solaris 2.1, in the file `libg++/configure.in', change

     *-*-solaris2)    my_host=solaris2 ;;

   to:

       *-*-solaris2*)    my_host=solaris2 ;;


Do I need to rebuild libg++ to go with my new g++?
==================================================

   "After I upgraded g++ to the latest version, I'm seeing undefined
symbols."

   or

   "If I upgrade to a new version of g++, do I need to reinstall
libg++?"

   This depends; as a rule, some upgrades will require rebuilding libg++
and others will not.  Both versions 2.3.3 and 2.4.0 introduced some
incompatibilities with previous versions.  For 2.3.3, the name mangling
of certain virtual table names changed, which introduced an
incompatiblity.  For 2.4.0, the type of "size_t" changed on Suns from
int (as declared by the include files provided by Sun) to unsigned long
(the ANSI C and draft ANSI C++ standards declare that size_t must be
unsigned, and the GCC maintainers are now correcting this "bug").

   Conclusion: if your old compiler is an older version than 2.3.3, you
must rebuild libg++ when you install a new g++.  If your vendor declares
size_t to be a signed type and your old compiler is an older version
than 2.4.0, you also must rebuild libg++.

   This would be a good opportunity to upgrade to the libg++ 2.3.1
release if you haven't yet, to minimize the amount of rebuilding.


User Problems
*************


Linker reports undefined symbols for static data members
========================================================

   "g++ reports undefined symbols for all my static data members when I
link, even though the program works correctly for compiler XYZ.  What's
going on?"

   The problem is almost certainly that you don't give definitions for
your static data members.  If you have

     class Foo {
         ...
         void method();
         static int bar;
     };

   you have only declared that there is an int named Foo::bar and a
member function named Foo::method that is defined somewhere.  You still
need to defined BOTH method() and bar in some source file.  According
to the draft ANSI standard, you must supply an initializer, such as

     int Foo::bar = 0;

in one (and only one) source file.


g++ won't accept the placement new syntax.
==========================================

   "I have a program that uses the "placement syntax" of operator new,
e.g.

        new (somewhere) T;

and g++ won't accept it."

   Up until version 2.3.1, g++ accepted an alternate form of the
placement syntax, for historical reasons; use

        new {somewhere} T;

if you are using g++-2.2.2 or older.

   As of 2.3.1, g++ finally fixed this, using the standard ARM syntax
for "placement new".  A few remaining glitches were fixed in 2.3.2.  The
only remaining problem is with declarators for pointers to functions;

     new (void (*)(int));  // confuses gcc 2.3.2
     new (a) (void (*)(int)); // ditto

   These can be worked around with a typedef:

     typedef void (*fun)(int);
     new fun;
     new (a) fun;


I think I have found a bug in g++.
==================================

   "I think I have found a bug in g++, but I'm not sure.  How do I know,
and who should I tell?"

   First, see the excellent section on bugs and bug reports in the gcc
manual (which is included in the gcc distribution).  As a short summary
of that section: if the compiler gets a fatal signal, for any input,
it's a bug (newer versions of g++ will ask you to send in a bug report
when they detect an error in themselves).  Same thing for producing
invalid assembly code.

   When you report a bug, make sure to describe your platform (the type
of computer, and the version of the operating system it is running) and
the version of the compiler that you are running.  Also provide enough
code so that the g++ maintainers can duplicate your bug.

   I will add some extra notes that are C++-specific, since the notes
from gcc are generally C-specific.

   First, mail your bug report to "[e-mail]".  You may
also post to gnu.g++.bug, but it's better to use mail, particularly if
you have any doubt as to whether your news software generates correct
reply addresses.  Don't mail C++ bugs to [e-mail].

   If your bug involves libg++ rather than the compiler, mail to
[e-mail].  If you're not sure, you could send your bug
to both lists.

   Second, if your program does one thing, and you think it should do
something else, it is best to consult a good reference if in doubt.  The
standard reference is "The Annotated C++ Reference Manual", by Ellis and
Stroustrup (copyright 1990, ISBN #0-201-51459-1).  This is what they're
talking about on the net when they refer to "the ARM".

   The reference manual, without annotations, also appears in
Stroustrup's "The C++ Programming Language, Second Edition" (copyright
1991, ISBN #0-201-53992-6).  Both books are published by Addison-Wesley.

   Note that the behavior of (any version of) AT&T's "cfront" compiler
is NOT the standard for the language.


Porting programs from other compilers to g++
============================================

   "I have a program that runs on <some other C++ compiler>, and I want
to get it running under g++.  Is there anything I should watch out for?"

   First, see the questions on placement new syntax and static data
members.

   There are two other reasons why a program that worked under one
compiler might fail under another: your program may depend on the order
of evaluation of side effects in an expression, or it may depend on the
lifetime of a temporary (you may be assuming that a temporary object
"lives" longer than the standard guarantees).  As an example of the
first:

     void func(int,int);

     int i = 3;
     func(i++,i++);

   Novice programmers think that the increments will be evaluated in
strict left-to-right order.  Neither C nor C++ guarantees this; the
second increment might happen first, for example.  func might get 3,4,
or it might get 4,3.

   The second problem often happens with classes like the libg++ String
class.  Let's say I have

     String func1();
     void func2(const char*);

   and I say

     func2(func1());

   because I know that class String has an "operator const char*".  So
what really happens is

     func2(func1().convert());

   where I'm pretending I have a convert() method that is the same as
the cast.  This is unsafe, because the temporary String object may be
deleted after its last use (the call to the conversion function),
leaving the pointer pointing to garbage, so by the time func2 is
called, it gets an invalid argument.

   If you think this is ugly, you should know that the ANSI C++
committee is still debating the lifetime-of-temporaries problem.

   For now, the safe way to write such code is to give the temporary a
name, which forces it to live until the end of the scope of the name.
For example:

     String& tmp = func1();
     func2(tmp);

   Finally, like all compilers (but especially C++ compilers, it seems),
g++ has bugs, and you may have tweaked one.


Why does g++ mangle names differently from other C++ compilers?
===============================================================

   See the answer to the next question.


Why can't g++ code link with code from other C++ compilers?
===========================================================

   "Why can't I link g++-compiled programs against libraries compiled by
some other C++ compiler?"

   Some people think that, if only the FSF and Cygnus Support folks
would stop being stubborn and mangle names the same way that, say,
cfront does, then any g++-compiled program would link successfully
against any cfront-compiled library and vice versa.  Name mangling is
the least of the problems.  Compilers differ as to how objects are laid
out, how multiple inheritance is implemented, how virtual function
calls are handled, and so on, so if the name mangling were made the
same, your programs would link against libraries provided from other
compilers but then crash when run.  For this reason, the ARM
*encourages* compiler writers to make their name mangling different
from that of other compilers for the same platform.  Incompatible
libraries are then detected at link time, rather than at run time.


What documentation exists for g++ 2.x?
======================================

   Relatively little.  The gcc manual describes the C front end, and
also the back end, which is shared by the C++ compiler, but there is
relatively little documentation for the C++ front end beyond a cursory
description of the command line options (although more C++ specific
information has been added to the gcc manual as of version 2.4.1).

   There is a Unix-style manual entry, "g++.1", in the gcc-2.x
distribution; this describes the extra command-line options that g++
supports, and the #pragma interface and #pragma implementation
directives.

   (Latest news: as of 2.4.0, these pragmas are finally described in the
main gcc manual).

   A draft of a document describing the g++ internals appears in the gcc
distribution (called g++int.texi); it is still incomplete.


What are the differences between g++ and the ARM specification of C++?
======================================================================

   The chief thing missing from g++ that is in the ARM is exceptions.
There are bits and pieces of exception code present, but it is not
presently usable.

   The template implementation is still new.  The implementation in
2.4.1 represents a considerable improvement over that of previous
releases, but it has a long way to go.

   g++ does not implement a separate pass to instantiate template
functions and classes at this point; for this reason, it will not work,
for the most part, to declare your template functions in one file and
define them in another.  The compiler will need to see the entire
definition of the function, and will generate a static copy of the
function in each file in which it is used.

   As with any beta-test compiler, there are bugs.  You can help improve
the compiler by submitting detailed bug reports.

   One of the weakest areas of g++ other than templates is the
resolution of overloaded functions and operators in complex cases.  The
usual symptom is that in a case where the ARM says that it is ambiguous
which function should be chosen, g++ chooses one (often the first one
declared).  This is usually not a problem when porting C++ code from
other compilers to g++, but shows up as errors when code developed under
g++ is ported to other compilers.

   [A full bug list would be very long indeed, so I won't put one here.
I may add a list of frequently-reported bugs and "non-bugs" like the
static class members issue mentioned above].


Will g++ compile InterViews?  The NIH class library?
====================================================

   The NIH class library uses a non-portable, compiler-dependent hack
to initialize itself, which makes life difficult for g++ users.  It
will not work without modification, and I don't know what modifications
are required or whether anyone has done them successfully.

   Brendan Kehoe of Cygnus Support is working on getting NIHCL to build
with g++.  He says, "The NIHCL release will hopefully contain patches
to gcc to let it build."

   [ From Steinar Bang <[e-mail]>]

   InterViews 3.1 compiles and runs with gcc-2.3.3 and libg++-2.3,
except that the "doc" application immediately dumps core when you try
to run it.  There is also a small glitch with idraw.

   There is a patch for InterViews 3.1 from Johan Garpendahl
<[e-mail]> available for FTP from site "ugle.unit.no".  It is in
the file

   /pub/X11/contrib/InterViews/g++/3.1-beta3-patch.

   This fixes two things: the Doc coredump, and the pattern menu of
idraw.  Read the instructions at the start of the file.

   [ I don't know whether the situation has changed with 2.4.0 ]


Debugging on SVR4 systems
=========================

   "When I use the -g flag on C++ code on a System V Release 4 system,
I get lots of undefined symbols at link time.  Why?  Help!"

   [From Ron Guilmette:] The changes needed to get the g++ front-end to
generate proper DWARF style debugging information for System V Release
4 are not yet completed, nor will they be until g++ version 2.4 (at the
earliest).

   (Guess what?  2.4 is out, and it *still* doesn't work, but now g++
will give you a warning message and turn off debugging rather than put
out bogus assembly code.  Latest word from Brendan Kehoe: "it should
work [better] in whatever major release comes after 2.4.1 ...").

   [Ron again:] There is nothing that you (as an end-user) can do to
correct this problem.  (It is actually *many* problems, and they are
all very complex.)  Until the g++ maintainers have time to fix this,
you should simply *avoid* using the -g option when using g++ on SVR4.


What are the rules for shipping code built with g++ and libg++?
***************************************************************

   "Is it is possible to distribute programs for profit that are created
with g++ and use the g++ libraries?"

   I am not a lawyer, and this is not legal advice.  In any case, I have
little interest in telling people how to violate the spirit of the GNU
licenses without violating the letter.  This section tells you how to
comply with the intention of the GNU licenses as best I understand them.

   The FSF has no objection to your making money.  Its only interest is
that source code to their programs, and libraries, and to modified
versions of their programs and libraries, is always available.

   The short answer is that you do not need to release the source to
your program, but you can't just ship a stripped executable either.

   Compiling your code with a GNU compiler does not affect its
copyright; it is still yours.  However, in order to ship code that
links in a GNU library such as libg++ there are certain rules you must
follow.  The rules are described in the file COPYING.LIB that
accompanies gcc distributions; it is also included in the libg++
distribution.  See that file for the exact rules.  The agreement is
called the Library GNU Public License or LGPL.  It is much "looser"
than the GNU Public License, or GPL, that covers must GNU programs.

   Here's the deal: let's say that you use some version of libg++,
completely unchanged, in your software, and you want to ship only a
binary form of your code.  You can do this, but there are several
special requirements.  If you want to use libg++ but ship only object
code for your code, you have to ship source for libg++ (or ensure
somehow that your customer already has the source for the exact version
you are using), and ship your applica        on in linkable form.  You cannot
forbid your customer from reverse-engineering or extending your program
by exploiting its linkable form.

   Furthermore, if you modify libg++ itself, you must provide source
for your modifications (making a derived class does not count as
modifying the library - that is "a work that uses the library").


Concept Index
*************

--
Joe Buck    [e-mail]